-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
manifests: Inherit from Project Sagano #2610
base: testing-devel
Are you sure you want to change the base?
Conversation
0cc0eaf
to
b7ce9a0
Compare
be2da25
to
5cd60c6
Compare
The technology and social goals here are intertwined: once we merge this, we'll need to think: Should the relevant work be done in Sagano or in FCOS? The definite goal of this PR once it lands is that some of the maintenance work of FCOS actually becomes Sagano work, to be clear. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is titled as demonstration only/WIP
, but I think you do want feedback on the idea/direction.
Overall I think the direction is where we want to go in the future (i.e. some "core" thing in Fedora that all other OSTree/ContainerNative distros are based on) so 👍 for that. I do think it would be worth us discussing this more in a forum like the weekly community meeting to at least socialize the direction and to see what other people think.
Were you intending for this to merge soon? For right now I don't think I'd be super comfortable with making a change like this just because of the infancy of the project (i.e. the code name didn't even exist until a few weeks ago and it still lives under cgwalters-playground
), but I think maybe once it gets more well established we could consider making a change like this?
Exactly, thanks!
OK, though this is a developer-only focused change right now to be clear.
Definitely not, as the commit message says:
But it's intended to be a conversational starting point as the project progresses. Thanks for the feedback! |
Right. It's definitely not end user facing (hopefully), but it does have implications on our overall structure in the future, which I think raises to the level of being meeting worthy. |
This looks sane to me too overall. I'm a bit confused though about https://gitlab.com/CentOS/cloud/sagano including both Fedora and CentOS manifests. ISTM like it'd be clearer to structure the repo as the common denominator and leave repo definitions and distro-specific stuff in one layer above? Ahh OK, I see https://gitlab.com/CentOS/cloud/sagano#plan, though I mean something slightly different. E.g.:
? That makes it easier for communities around each of Fedora and CentOS to work on their respective bases without incurring unnecessary churn on the other. |
To me an explicit goal is to fix the problem with Fedora CoreOS ➡️ ??? ➡️ RHEL CoreOS today. And specifically, a goal of Sagano is to be "ready to ship" even in CentOS Stream 9. Another related goal is sharing tooling with things like automotive that only have CentOS versions at the moment. Also not unrelated to this, a goal is to build on the momentum from RHT investment in gitlab.com at an OS level and the CI flows there. And to help build the story with integration into dist-git gating. With these things combined, splitting things up between Fedora and CentOS adds more friction to my mind. Particularly to the scale of all the git repositories you're proposing! But obviously for now, fedora-coreos-config continues to be in github. That still works fine. And more generally remember, a bigger goal here is that we do container native derivation which works just great today with |
A simple thing to game out: What happens when in e.g. fedora rawhide something changes in say the grub/systemd/whatever packaging and we need a change that's rawhide only in the manifest? How does that work? Do we branch in that git repository? My first response here is that we already have some support for conditionals and rather than git branches we should make it work like spec files. Will this cause problems? Maybe. But, my feeling is that that cost is going to be dramatically outweighed by the benefits of not allowing things to drift by default and keeping things centralized. EDIT: Right now every PR to the sagano Git is gating on Fedora 38 and C9S, and I think that's a really nice improvement. |
5cd60c6
to
a0d450a
Compare
OK, the sagano git repository is now in a more stable place; lifting draft on this. |
SGTM. Though maybe let's wait until we've cleared f39 GA first? Also, let's do #2609 first? (Did you see the comments there BTW?) |
a0d450a
to
b4d70ed
Compare
This is prep for rebasing on [sagano](https://gitlab.com/cgwalters-playground/sagano) where I hit on the issue that to build images with `kernel-rt`, we need to clearly separate the `kernel` package from userspace stuff (`systemd`, `rpm-ostree`) etc. Note that we'll need to make the same change in RHCOS - until we rebase both on sagano.
Fedora CoreOS predates the time of bootable containers. As such, it's actually pretty large (relatively speaking). Project Sagano is a fresh take on more minimal base images. At the same time, we want to de-duplicate efforts. With this, CoreOS cherry picks a few manifests from the Sagano "tier-0" and "tier-1". There's *definitely* more we can share between the two, but this is a notable starting point.
b4d70ed
to
06d27db
Compare
Depends #2609
manifests: Inherit from Project sagano
[This is just a demonstration/testing change; the git repository
for Sagano is definitely going to change location at least]
Fedora CoreOS predates the time of bootable containers. As such,
it's actually pretty large (relatively speaking). Project Sagano
is a fresh take on more minimal base images.
At the same time, we want to de-duplicate efforts. With this,
CoreOS cherry picks a few manifests from the Sagano "tier-0" and
"tier-1".
There's definitely more we can share between the two, but
this is a notable starting point.